I've just run accross a behavior for Service pack 3 for Exchange 2007 that is very different than the expected behavior when you run the /PrepareAD switch. To sum up, /PrepareAD does run successfully and reports that everything went well, but it does not update the schema. The "rangeUpper" value of "ms-Exch-Schema-Version-Pt" stays at 14622 instead of updating to 14625. I've double checked the documentation (http://technet.microsoft.com/en-us/library/bb125224(v=exchg.80).aspx) and it does state in the note under step 2 (/PrepareSchema) that "You can skip this step and prepare the schema as part of Step 3." Step 3 being the /PrepareAD switch. The doc also states that you can skip /PrepareLegacyExchangePermissions as well, if your going to run /PreareAD. All other Exchange 2007 service packs that I have installed update the schema as part of the /PrepareAD switch, in line with what is stated in the documentation. What I found: /PrepareAD creates a Powershell script in the ExchangeSetuplogs directory called "Install-ExchangeOrganization-"Date"-"Time".ps1". Looking at the top of the script created by an Exchange SP2 update, you can see that "$RolePrepareSchema = $True". If you look at the script created by Exchange SP3, you see that "$RolePrepareSchema = $False". So it looks as if the SP3 setup creates a script that doesn't update the schema, which is weird since all documentation and previous service pack behavior says it should. These scripts are auto-generated by the setup program, so I don't know why it changed in Exchange SP3. My environment: Domain is mixed 2003 - 2008R2 (middle of a domain upgrade) Schema Master, and all other FSMO roles are on 2008R2 domain controllers. Exchange server 2007 SP2 rollup 5, upgrading to SP3 rollup 6 "rangeUpper" value of "ms-Exch-Schema-Version-Pt" prior to running /PrepareAD "14622" (Exchange schema version) "objectVersion" value of "cn=schema,cn=configuration,dc=mydomain" "47" (AD schema version) Not sure if the mixed mode of my domain caused the setup file to not flip "$RolePrepareSchema" to True, but I also haven't run across any documentation that states is would, or that you shouldn't update the schema in mixed mode. Interestingly Exchange 2010 RTM's "rangeUpper" value is "14622", so you cannot run /PrepareSchema in an Active Directory that has already been extended by Exchange 2007 SP3 /PrepareSchema, since it will fail the organizational checks. You have to use Exchange 2010 SP1. (see http://social.technet.microsoft.com/wiki/contents/articles/2772.exchange-schema-versions-common-questions-answers.aspx) Makes one wonder if the SP3 /PrepareAD behavior is built in to prevent this issue. Does anyone know of any reason not to force the schema update by running setup.com /PrepareSchema, given the situation above? I've run it in my lab environment, and have not seen any ill effects. However, the lab has fewer servers, and types of servers, than my production environment, and I'm guessing that there must be a good reason why the service pack 3 /PrepareAD didn't actually run the /PrepareSchema operations.

I'm marking the post from Fiona as the answer, since that the only way you'd get the /PrepareAD option to work the way it should on the first try. However, I'm sure that running /PrepareSchema option will finish the AD preparation that /PrepareAD missed. I've checked this by comparing the variable options in SP2's powershell script against SP3's powershell script. I'm thinking that if /PrepareSchema runs without a problem, then it probably is an issue with the SP3 setup. I would have still liked to have seen something from MS on that though. If anybody does have an official link that describes this behavior as a "known issue", please post it in this thread.

Hi Rexif, Thanks for your update. I have already involved a next level engineer in this thread, will keep you posted if there is any update. Fiona Liao TechNet Community Support

Hi Fiona, Thanks for doing that. Looking forward to seeing what you find.

There is no direct article about the issue , closest one is here http://support.microsoft.com/kb/2457729 The issue reported in the KB is due to Schema upgrade mismatch.

Sureshbd-MSFT, Thanks for the post. Makes the argument for running the /PrepareSchema for this issue even stronger.